OPC UA offers several ways of authenticating users, such as anonymous, username and password, or X.509 certificate. This corresponds to different user identity token types. The user authentication steps verifies that the user is who he/she claims to be. OPC Wizard offers user manager objects for common authentication methods, and you achieve the user authentication simply by configuring the user managers. You can also do custom handling by taking over the user authentication and prividing your own code to handle it.
OPC UA recognizes 4 types of user identity tokens:
You, as a developer, decide which user identity token types will be made available by the server. This is done using the IEasyUAServer.UserIdentityTokenTypes Property.
By default, all supported user identity token types are enabled. The OPC UA server exposes the available user identity token types using OPC UA discovery mechanism, and OPC UA clients can view them. By default, all supported user identity token types are enabled. If your server does not offer specific token type, you should remove it from the UserIdentityTokenTypes Property, otherwise the information offered to OPC UA clients will be confusing. E.g. if you are developing a server that does not actually ever authenticate the users, you should only keep the Anonymous Field flag in this property. Conversely, if the server always requires username&password authentication, and no anonymous users whatsoever, keep only the UserName flag in this property.
The following example shows how to implement an OPC UA server that does not use user authentication, and only allows anonymous access.
If a specific user identity token type is not made available by the OPC UA server, there is no corresponding endpoint configuration that the OPC UA client can use with this token type. It is therefore not necessary to add extra precautions in subsequent access control steps to deny access to users connecting to the server using a user identity token type that is not in the UserIdentityTokenTypes Property, because such connection simply cannot be made at all.
If the OPC UA client is connecting to the OPC Wizard server using one of the user identity token types made available as described above, OPC Wizard then attempts to authenticate the user. This is done by user manager objects. There is one user manager object for every supported type of user identity token.
Your code can configure the user managers so that they provide the authentication you need. The user managers are accessible through the UserManagers Property on the EasyUAServer Class.
The anonymous user manager is used when an anonymous user identity token is used by the OPC UA client to establish the connection. It is a simplistic user manager, as all anonymous users are treated the same. It is accessible through the Anonymous Property of the UserManagers Class.
By default, this property contains an instance of the MemoryAnonymousUserManager Class. For configurable properties of the anonymous user manager, see OPC Wizard User Authorization.
The username/password user manager is used when a username and password user identity token is used by the OPC UA client to establish the connection. The manager checks whether the username represents a known user, and whether a correct password has been specified by the OPC UA client for the user. It is accessible through the NameAndPassword Property of the UserManagers Class.
By the default, OPC Wizard uses an instance of the MemoryNameAndPasswordUserManager Class for the username/password user manager. This is an in-memory implementation of such user manager. You can create new users using the Create Method, and remove them using the Delete Method. Besides authentication, the user manager also handles authorization tasks - for details, see OPC Wizard User Authorization.
The following example shows how to implement an OPC UA server that only allows access authenticated with username and password.
The contents of the MemoryNameAndPasswordUserManager Class (the users and all information associated with them) can be saved to file using the SaveToFile Method, or loaded from file using the LoadFromFile Method.
Only hashes of passwords are kept in memory and/or saved to a file. The MemoryNameAndPasswordUserManager Class does not persist the passwords themselves.
The behavior provided by default anonymous and username/password user managers should be sufficient for most servers. In some scenarios, however, more customization of the authentication process is needed. For example, you might have a separate subsystem that already handles the authentication (and/or authorization), and although it might be possible to extract the authentication information from it and load it into the MemoryNameAndPasswordUserManager Class, such solution has several disadvantages.
In cases like this, you can customize the user authentication and provide your own code to do it. Two approaches can be used:
In order to replace the default username/password user manager, you can write a class that implements the IReadOnlyNameAndPasswordUserManager Interface. You then assign an instance of your class to the ReadOnlyNameAndPassword Property in the UserManagers Class. Note that it is not necessary to implement the "full" INameAndPasswordUserManager Interface (which includes method for modification of the user list and user properties) in order to develop a functioning OPC UA server.
By handling the VerifyUser Event on the EasyUAServer Class, you can provide a fully custom logic to authenticate a user's identity token. The event is being passed an instance of VerifyUserEventArgs Class, where the user identity token is available as an input. Use the HandleAndReturn Method to indicate that your code has taken over the authentication and is returning a corresponding result. If your code does not indicate that it has handled the event, OPC Wizard will continue by attempting to authenticate the user by interrogating the user manager objects, as described above.